Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests/kola: use latest fedora:latest on tests that require it #3123

Closed

Conversation

marmijo
Copy link
Member

@marmijo marmijo commented Aug 26, 2024

Both ntp.chrony.dhcp-propagation and podman.rootless-systemd use the Fedora container to set up the environment for the test. Always use the fedora:latest container so we never use EOL Fedora releases in kola tests.

both `ntp.chrony.dhcp-propagation` and `podman.rootless-systemd` use
the Fedora container to set up the environment for the test. Always
use the `fedora:latest` container so we never use EOL Fedora releases
in kola tests.
@marmijo marmijo force-pushed the use-latest-fedora-container branch from 29b98ea to 6325585 Compare August 26, 2024 16:56
@marmijo marmijo enabled auto-merge (rebase) August 26, 2024 17:02
@dustymabe
Copy link
Member

hmm. I feel like we pin on purpose (since moving tags move at times which could be inopportune for us). Don't we usually bump these when we switch to a new Fedora major?

I guess another way to phrase this line of questioning.. what problem are we solving?

@jlebon
Copy link
Member

jlebon commented Aug 26, 2024

@dustymabe See the commit message in openshift/os#1583 for details.

But yeah, also not sure about this even though I agree it's a logical follow-up to openshift/os#1583. One difference from that PR though that motivated me there is that in the extensions case, we're doing something trivial with the Fedora image: installing createrepo_c and generating repodata. It felt to me like something unlikely to break.

The tests here OTOH are doing more complex things like dnsmasq, httpd, and running systemd as init in the container... which I can definitely imagine breaking. And we don't want e.g. a broken dnsmasq or systemd update in the latest Fedora to suddenly break all our streams.

I guess easiest short-term is to add a new fedora-archive.repo file that points to the archived location to work around the current issues.

I still think the cleanest approach for these tests though is to eventually use content from the same compose we're building from (openshift/os#1546).

@dustymabe
Copy link
Member

@dustymabe See the commit message in openshift/os#1583 for details.

But yeah, also not sure about this even though I agree it's a logical follow-up to openshift/os#1583. One difference from that PR though that motivated me there is that in the extensions case, we're doing something trivial with the Fedora image: installing createrepo_c and generating repodata. It felt to me like something unlikely to break.

Even there maybe we should be using CentOS or RHEL instead. I could foresee a case where create_repo adopted a new feature or default that older clients couldn't handle.

The tests here OTOH are doing more complex things like dnsmasq, httpd, and running systemd as init in the container... which I can definitely imagine breaking. And we don't want e.g. a broken dnsmasq or systemd update in the latest Fedora to suddenly break all our streams.

correct.. or even something as simple as glibc updates in newer Fedora containers not being compatible with older branched OS. I vaguely remember cases where older OS couldn't run newer containers.

I guess easiest short-term is to add a new fedora-archive.repo file that points to the archived location to work around the current issues.

I still think the cleanest approach for these tests though is to eventually use content from the same compose we're building from (openshift/os#1546).

👍

@jlebon
Copy link
Member

jlebon commented Aug 26, 2024

But yeah, also not sure about this even though I agree it's a logical follow-up to openshift/os#1583. One difference from that PR though that motivated me there is that in the extensions case, we're doing something trivial with the Fedora image: installing createrepo_c and generating repodata. It felt to me like something unlikely to break.

Even there maybe we should be using CentOS or RHEL instead.

That actually used to be the case, but we moved to Fedora because of openshift/os#1000. We might be able to revisit this now. (Obviously something we'd need to figure out too for openshift/os#1546.)

@travier
Copy link
Member

travier commented Aug 27, 2024

I've just realized that we actually have such a potentially breaking change coming in Fedora 41: https://discussion.fedoraproject.org/t/f41-change-proposal-upgrade-systems-to-createrepo-c-1-0-and-change-repositories-metadata-settings/108893

So openshift/os#1583 might be a risk as well.

marmijo added a commit to marmijo/fedora-coreos-config that referenced this pull request Aug 29, 2024
Certain kola tests on older RHCOS branches rely on EOL fedora
containers to set up and run the test environment. Right now,
the older content can be found on the mirrors, but as part of the
RHCOS pipeline migration effort to the ITUP cluster, we have to
explicitly specify each outbound connection.

Add a `fedora-archive.repo` file to be used in these tests so we can
always download the older content from: https://dl.fedoraproject.org

see: coreos#3123 (comment)
@marmijo
Copy link
Member Author

marmijo commented Aug 29, 2024

I guess easiest short-term is to add a new fedora-archive.repo file that points to the archived location to work around the current issues.

I opened #3128 as a first attempt at that.

marmijo added a commit to marmijo/fedora-coreos-config that referenced this pull request Sep 3, 2024
Certain kola tests on older RHCOS branches rely on EOL fedora
containers to set up and run the test environment. Right now,
the older content can be found on the mirrors, but as part of the
RHCOS pipeline migration effort to the ITUP cluster, we have to
explicitly specify each outbound connection.

Add a `fedora-archive.repo` file to be used in these tests so we can
always download the older content from: https://dl.fedoraproject.org

see: coreos#3123 (comment)
dustymabe pushed a commit that referenced this pull request Sep 4, 2024
Certain kola tests on older RHCOS branches rely on EOL fedora
containers to set up and run the test environment. Right now,
the older content can be found on the mirrors, but as part of the
RHCOS pipeline migration effort to the ITUP cluster, we have to
explicitly specify each outbound connection.

Add a `fedora-archive.repo` file to be used in these tests so we can
always download the older content from: https://dl.fedoraproject.org

see: #3123 (comment)
@marmijo
Copy link
Member Author

marmijo commented Sep 4, 2024

Closing because it was decided that #3128 would be the solution here

@marmijo marmijo closed this Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants